Systems and methods consistent with the exemplary embodiments relate to a matrix security management system that allows administrators to manage rights and privileges for principals over resources in a computer system or computer network. Principals refer to principal groups and individual principals, for example user groups and users. Resources refer to resource containers and individual resources, for example folders and files. In particular, the exemplary embodiments relate to improvements in visualizing and assigning large and complex file permission settings for a computer system or network.
Systems and methods of the related prior art allowed IT administrators to assign rights and privileges over resources in a computer system or network, but did so in a way that made it difficult for the administrator to quickly, easily and correctly implement security settings for large computer systems or networks and to comprehensively monitor existing security settings for mistakes in security settings and/or security breaches. This was especially true for large and complex networks where the number of resources and users created an overwhelming amount of information that could not be practically viewed on prior art network administrator user interfaces. More specifically, two main challenges facing the administrator of any computer system are: 1) setting up security (rights and access between groups and contents); and 2) monitoring the security deployment to ensure that security breaches have not occurred by auditing the security system.
Setting up security for a computer system is done on an individual basis: each user or user group (“security principal”) is granted rights to a computer resource (e.g., workstations, computer drives, folders, files, printers, programs, processes, apps, database tables, database views, etc.) one at a time. Additionally, administrators may grant rights to a resource at various granularity levels, for instance granting a user one set of rights at a folder level, but also having the ability to grant the user a separate set of rights to a file contained within the folder. This ability to set rights at different granularity levels often leads to improper security access being granted to users, which then leads to security breaches and unauthorized access of sensitive information, or may lead to improper access denial to computer resources for a user which causes end user frustration and/or customer service complaints to the network administrator (see FIG. 13).
In recent years, a new problem has emerged for IT administrators in the form of Government mandated data security regulations, examples of which include HIPAA and Sarbanes-Oxley in the United States and Basel and Solvency in the European Union. These regulations require that greater security measures be undertaken to prevent data breaches involving sensitive personal information, such as medical records, or to create “internal controls” that police against unauthorized transactions or manipulation of internal corporate data, such as financial data. While there are other security tools that can help secure a computer system from outside intruders, such as the implementation of digital certificates, private-key cryptography, encrypted passwords, etc., these methods provide no protection if the user authentication process for all of the software, files, and other computer resources on the network is not properly set and maintained. Any mismanaged user rights may grant access to inappropriate content to one or more users, exposing the company and its clients to economic harm, legal liability, or public embarrassment. Furthermore, for government institutions, such as the military or intelligence agencies, such unauthorized access of materials may lead to the public disclosure of sensitive or classified information.
Additionally, for popular websites such as financial websites, social media websites (e.g., Facebook, Twitter, etc.), and webmail websites (e.g., Gmail, Yahoo, etc.), that provide their users with individual accounts, encryption tools provide incomplete protection of important username and password information because they cannot protect the user from hacking and “phising” of their account passwords. These user account breaches have been known to lead to wider spread data security breaches due to the improper application of security rights for such compromised user accounts. Having the proper level of computer permissions set on each user account helps to mitigate the amount of damage done by a hacking/phising attack by limiting the hacker's access to just the account of the individual user that he hacked, and not to the entirety of the computer system.
Current operating systems, such as UNIX, Linux, and Microsoft Windows, and enterprise software systems, such as databases, email programs, or SaaS software, provide security and permissions tools integrated into the software system, however these tools often are not user-friendly and can lead to errors in setting or maintaining security permissions. For example, Microsoft provides administration tools for managing NTFS security and access (see FIGS. 1-3) in its Windows operating systems that support the NTFS file system (e.g., Windows NT 3.1, Windows NT 3.5, Windows 2000, Windows XP, Windows Vista, Windows 7, and Windows 8), but these tools are often difficult and confusing to use, even for sophisticated users such as computer administrators. As can be seen in FIGS. 1-3, and as users of Microsoft Windows would understand and appreciate, permissions have to be managed individually for each file or folder in order to allow or deny access to users and groups from windows. One of ordinary skill in the art would understand that the more computer resources there are that need securing and the more groups and users there are that need to be given permission to access and modify the computer resources, the longer, more repetitive and more prone to error the process becomes (see also FIG. 13, which depicts the steps an administrator has to take in order to set security permissions in a Microsoft Windows 2008 Advanced Server). While this may be acceptable for small computer systems or networks that have a small number of users and a limited number of computer resources to protect, for large companies and large software deployments, it can amount to thousands of input screens and thousands of mouse clicks. Multiplying the number of existing computer resources by the number of users identified in the system gives an idea of the overall number of possible permissions combinations. Thus, there is a substantial risk of administrative error and an excessive amount of time spent administrating the system.
And even when the implementation of security settings is complete, maintaining, updating, and understanding the security setup becomes impossible. Routine security auditing questions such as determining what an individual user can see, modify, create, or determining who can see, modify and delete specific content becomes time-consuming tasks for IT administrators. Therefore, auditing security globally is a very difficult task to implement using currently available solutions.
Moreover, computer resources and security principals are often organized and classified under hierarchies, sometimes representing the organization's structure. For example, network shared files may be classified in a folder hierarchy and domain users in a user group hierarchy that reflect the groups and subgroups of a company or other organization. In such a hierarchy, principals and computer resources may have multiple antecedent (i.e., parent) and descendant (i.e., child) principals or resources in its hierarchy. Therefore, permissions inheritance makes the implementation and understanding of software security more complex. The effective permissions for a principal over a resource consist of two types of permissions: explicit permissions and inherited permissions. Explicit permissions are those that are set by default when the resource is created, or by an administrator action. Inherited permissions are those that are propagated to a resource from a parent resource. Therefore, the effective permissions existing between a principal and a computer resource are made of merged inherited permissions that have been previously established for the principal antecedents and the computer resource, or the resource's antecedents, and explicitly set permissions. For example, if the “delete” permission has been granted to a user for a specific file, but the permission has been denied for the user's antecedent group, the resulting merged right will be granted based on the underlying software or operating system's default security permissions' merging rules. And in the case of NTFS-based Windows operating systems, the merging rule for these situations is that explicit permissions take precedence over inherited permissions, even inherited deny permissions. Further complicating matters is the fact that merging rules vary by operating systems and software systems, thus complicating the administration of computer system/network and software systems, especially if the administrator is overseeing multiple software systems or operating systems that have different default merging rules. Furthermore, because the permission that is set for an antecedent principal/resource may differ from the permission set for a descendant principal/resource, in some prior art user interfaces it was difficult to determine what the actual security permissions of a principal were without investigating every antecedent or descendant resource and principal to see whether under the system's merging rule the permission was set as the administrator intended.